You Might Not Need a Design System
Your company doesn’t need a design system. What you need is a good product.
Notion, for example, scaled to 100M users without a design system. And it’s known for its consistent and intuitive design. Clearly, a design system isn’t the only valid approach.
Before you create a design system, ask yourself: “Why?” What problem are you trying to solve? Designers wanting to build a design system because it’s trendy is not a good reason. That’s a solution in search of a problem.
Here are some real problems that might warrant a design system:
“Our product is visually inconsistent. We’d like to audit and simplify our design language.”
“Our engineers feel disempowered because they have to create everything from scratch. They have little autonomy and need to pull in designers for help with everything.”
“Our design and engineering teams aren’t speaking the same language and need a shared framework for thinking about components.”
Even in these cases, you STILL might not need a design system. The most common reason is that you already have one!
If your app is built in a modern framework like React, you’ve had a design system since day one. It’s a bunch of files in a folder called components, and it’s better than anything you’ll ever build in Figma.
Your design system is real. It exists in code. It’s 100% up-to-date and represents every edge case and obscure state you could imagine. The only problem is that some of your designers can’t see it.
But how can a design team improve a design system they can’t see? The simplest way is to open the components folder and ask the engineers why there are files called ButtonA, ButtonB, and ButtonC. Why are these separate components? Can we consolidate these into one and make them more consistent?
Every engineer loves deleting code, so you’ll have a perfect button component in 10 minutes. Go ahead and crack open Figma and draw a few buttons if it helps communicate your ideas to the engineer. Until a company is huge, the best design system is good communication.
If your product gets really big, it may be beneficial to use something like Storybook to visually document your component library in code, but you definitely don’t need to start there.
Design systems that live in Figma are ultimately tools for designers. Build a library of Figma components if it helps your design team move faster, but don’t expect it to align perfectly with the design system that lives in code. Remember, the code will always be the source of truth.
Whatever you do, don’t fall into the trap of building a design system too early. Default to design freedom. Sprinkle in a few rules later if it helps you move faster.
Engineers know there is nothing more dangerous than a premature abstraction. Adding complexity and process before knowing the final requirements of a system will always set you up for pain down the road. The best designers and design teams understand this too. They reach for tools to solve problems and recognize that design systems are just one of many possible solutions.